1. Field of the Invention
The present invention relates to technology for splitting multimedia type-specific terminals of a push-to-talk-over-cellular (PoC) system to transmit media.
2. Description of the Related Art
Significant developments in mobile communications technology and the extension of mobile communications networks have resulted in the development of a vast array of services and applications for use with a cellular phone. At the same time, demand among cellular phone users for these additional services, such as a location service, a multimedia service, and a push-to-talk (PTT) service, is increasing. The PTT service supports various supplementary functions such as an instant messenger function and a status display function, as well as a group call and a voice call which are also provided by an existing radio or a trunk radio system (TRS).
Currently, standardization of a push-to-talk-over-cellular (PoC) service that employs the PTT function in a mobile communication network is taking place. A unique feature of the PoC service is that a user can participate in a plurality of PoC sessions and can also use a call service while switching from the PoC sessions as desired. This feature is a requirement that is specified in the open mobile alliance (OMA), which is a forum for specifying mobile communications services.
FIG. 1 is a schematic diagram of a conventional PoC service system. Referring to FIG. 1, a PoC client 10, as a service requester installed in a mobile station, is generally connected to a Session Initiation Protocol/Internet Protocol (SIP/EP) core network 30 that supports SIP and IP multimedia functions via an access network 20.
The PoC client 10 resides in a PoC user terminal to provide access to the PoC service. The PoC client 10 mainly serves to establish, participate in and terminate a PoC session. In addition, the PoC client 10 makes and transfers a talk burst, supports an instant personal alert and performs authentication when accessing the PoC service. Hereinafter, unless otherwise stated, the PoC client 10 is assumed to be the same as a PoC service subscriber or PoC terminal.
The SIP/EP core network 30 is connected to a PoC server 60, a GLMS (Group List and Management System) 50, and a presence server 70 in order to support the PoC service.
Generally, SIP is a standard defined in the IETF (Internet Engineering Task Force) RFC (Request for Comments) 2543. SIP is an application-layer control protocol that is used to set up, modify and terminate a session or call for multimedia communication such as video and voice communication. SIP exists over a UDP (User Datagram Protocol)/TCP/IP layer, which supports both unicast and multicast sessions for initiating a session by inviting participants to a multimedia conference with a client/server protocol capable of exchanging SIP Request and Response messages in a request/response fashion.
The SIP Request message provides six functions in RFC 2543 as follows: INVITE (Invitation to participate in a session), ACK (Acceptance of an INVITE request), BYE (Termination of a call), REGISTER (Registration with a redirect server by a user agent), CANCEL (Cancellation of a pending request), and OPTIONS. The SIP Response message provides status codes as follows: 1xx (Information response), 2xx (Success response), 3xx (Redirection response), 4xx (Client Error, Request Failure), 5xx (Server Error), and 6xx (Global Failure).
The PoC server performs a Controlling PoC Function (CF) of controlling overall maintenance and management of a PoC session and a Participating PoC Function (PF) of controlling maintenance and management between each PoC session, which will be explained below with reference to Tables 1 and 2.
TABLE 1Controlling PoC Function (CF)Provides centralized PoC session handlingProvides centralized Media distributionProvides centralized Talk Burst Arbitration functionality including talkeridentificationProvides SIP session handling, such as SIP session origination,termination, etc.Provides policy enforcement for participation in group sessionsProvides participant informationCollects and provides centralized media quality informationProvides centralized charging reportsMay provide transcoding between different codecsSupports Talk Burst Control Protocol Negotiation
As shown in Table 1, the CF serves to maintain and manage a PoC session. The PoC server receives requests for the floor from PoC clients, arranges an order in which to give the clients the floor, and gives the clients the floor in that order. The PoC server also distributes a talk burst, for which an arbitrary PoC client makes a request, to all other PoC clients participating in a group PoC call, and provides information of the PoC clients participating in the group PoC call.
As shown in Table 2 below, the PF manages a PoC session between the CF and each PoC client. Particularly, the PF relays the floor between the PoC client and the CF when the PoC client makes a request for the floor or when the CF gives the floor to the PoC client. In addition, the PF relays media between the CF and the PoC client, performs transcoding between different codecs, and filters one of two concurrent PoC sessions according to the choice of a PoC user when there is simultaneous talking in the two active PoC sessions.
TABLE 2Participating PoC Function (PF)Provides PoC session handlingMay provide the Media relay function between PoC client and ControllingPoC serverMay provide user media adaptation proceduresMay provide the Talk Burst control message relay function betweenPoC client and Controlling PoC serverProvides SIP session handling, such as SIP session origination,termination, etc, on behalf of the represented PoC client.Provides policy enforcement for incoming PoC session (e.g. accesscontrol, incoming PoCsession barring, availability status, etc.)May collect and provide media quality informationProvides participant charging reportsMay provide filtering of media streams in the case of simultaneoussessionsMay provide transcoding between different codecsMay support Talk Burst Control Protocol NegotiationStores the current Answer Mode and Incoming PoC Session Barringpreferences of the PoC client
In the PoC service system described above, the PoC user can input information on a group and its members to the GLMS 50 through his/her PoC terminal, and can receive information about PoC users whom he or she can call through an individual or group list transmitted from the GLMS 50. Alternatively, the information on the group and its members may be input, modified and managed in the GLMS 50 via a reliable communication network such as the Internet or an Intranet.
In order to use the PoC call service, the PoC user registers his/her PoC address with the SIP/IP core network 30. The SIP/IP core network 30 stores PoC user information at the request of the PoC user. Thus, when another PoC user tries to request a group PoC call, the PoC user registers his/her information in the SIP/IP core network 30 in advance, and requests the group PoC call to his/her SIP/IP core network by using group identification information transmitted from the GLMS 50. At this time, the SIP/IP core network 30 performs address determination and domain location determination by using information of the call requesting PoC user and then transfers a PoC call request to a home PoC server with which the call requesting PoC user is registered. In regard to the PoC call request, the PoC server prepares to establish a PoC session, obtains each user's information from the GLMS, and then transfers a PoC call request signal to a corresponding SIP/IP core network. When a PoC call request is made to users within an Intradomain, the PoC server performs both the CF and PF. The PoC server, which manages a call-requested PoC user, requests a PoC call to the PoC user after the SIP/IP core network performs the locating procedure, by using information of the PoC user that is transmitted to the PoC server.
Features of the PoC system in the OMA are as follows.
The PoC system is divided into an on-demand session mode and a pre-established (or early) session mode, according to the connection with a PoC server within a user's home network.
The pre-established session mode is designed so that the PoC user sets up a session between a PoC client and a PoC server belonging to a PoC user's home network in advance by PoC user's request. The pre-established session enables the PoC user to negotiate media parameters to be used with the PoC server in advance, and thus perform rapid call setup without renegotiating the media parameters to be used in the future between the PoC server and client. In order to set up the pre-established session, the PoC client provides supported media parameters to a Session Description Protocol Multipurpose Internet Mail Extensions (SDP MIME) body through a method of SIP INVITE, and responds to the media parameters provided from the PoC server. The PoC client sends, to the PoC user, identification information of the pre-established session for a response message received from the PoC server, together with a conference Uniform Resource Identifier (URI). When using the pre-established session, it is possible to pre-negotiate such parameters as an IP address, a port number, a codec to be used and a talk burst control protocol.
The on-demand session mode refers to a state in which the PoC user does not set up the pre-established session, and indicates that the PoC user performs a PoC call connecting procedure after receiving an INVITE message of another PoC user.
Meanwhile, the PoC system enables the PoC to make a half-duplex group call in addition to the foregoing features. This multilateral conferencing function is a representative feature of the PoC, and is divided into an ad-hoc PoC group, a pre-arranged PoC group and a chat PoC group according to how it is set up.
In the PoC system having the foregoing features, respective elements such as the PoC client, PoC server, SIP/IP core network, group list server and presence server, as well as procedures of initiating and connecting an initial PoC session through signaling between these elements can be found from the OMA standard draft as the conventional SIP-based technology. Thus, their description will be omitted herein.
A procedure for establishing a PoC multimedia session in the PoC system will be described below. The procedures for session establishment with respect to each PoC group are similar. The same procedure is repeated for all members in order to establish the group session. Hence, the procedure for establishing the PoC multimedia session will be described on the basis of a procedure for establishing the session for one PoC member. To this end, the procedure for establishing the PoC multimedia session will be described with reference to FIGS. 2 and 3. In FIGS. 2 and 3, an originating side requester for a PoC call makes a request for call processing by sending a multimedia invitation message using a SIP protocol (herein, the case of requesting audio and video calls is considered by example). On a terminating side, an auto answer mode is set up, and a pre-established session exists. Under these conditions, call processing procedures of call originating and terminating sides implemented by the prior art are each described.
FIG. 2 shows a signaling flow for a conventional process of connecting the PoC multimedia session of an originating side.
Referring to FIG. 2, a PoC client A sends an INVITE message, which includes the SIP address of a receiver to whom the PoC client A desires to talk, to an SIP/IP core A (S11). At this time, the INVITE message includes elements such as information on the PoC address of a call request client, requested media parameters (since the requested session is based on the multimedia, which has various media attribute values such as an encoding method referring to audio and video, a rate, and a payload type), and information on an attribute value informing PoC service, etc. The INVITE message is transmitted to a PoC server (hereinafter PF A), which controls a participating function via corresponding servers (Proxy Call Session Control Function (P-CSCF) and Serving Call Session Control Function (S-CSCF)) in an IMS network through a route query at a Dynamic Host Configuration Protocol (DHCP) server or DNS server (S12). Since the PF A, to which a PoC user is connected when a general call request is made, can be split from a PoC server X (hereinafter CF X) that manages the talk burst of an established session, the INVITE message forwarded through steps S11 and S12 is transmitted to the CF X via an SIP/IP core network of each network (S13, S14 and S15).
A controlling network including the CF transmits the INVITE request forwarded through step S15 to the corresponding SIP/IP core network, and then receives a response message. An SIP message with which the terminating side network responds may be one of provisional response messages of 1XX, successful response messages of 2XX, and error response messages of 4XX, 5XX and 6XX (herein, the description will be oriented to a normal call processing procedure within a range that does not deviate from the fundamental effect of the present invention). After step S15, the CF can receive an AUTO-ANSWER or OK response according to an answering mode of the terminating side. Alternatively, in the case of the AUTO-ANSWER response of FIG. 2, the CF may receive a signal SIP 183 Session Progress, and thus perform connection between the PoC server and client in the IMS network of the call requester. A call acceptance signal of the receiver is sent as the SIP 183 Session Process or SIP 200 OK response, and forwarded to the PoC client A via the PoC servers of the CF and PF (S16 through S20).
Meanwhile, after receiving the 200 OK or 183 Session Progress response from the PoC server of the terminating side, the CF determines whether a PoC call is connected or not, and then sends a Floor Granted signal that grants the talk burst floor to the PoC client A. Granting the talk burst authority according to the response (200 OK or 183 Session Progress) may be divided into confirmed and unconfirmed types, which explains why the CF requires a buffering function.
After receiving the acknowledgement response signal to the INVITE request signal (S16 through S20), the PoC client A receives the Floor Granted signal in order to forward a talk burst transmission enable signal (ring back tone) using an Real-time Transport Control Protocol(RTCP) protocol (S21 and S22). At this time, the Floor Granted signal is generated from the CF having the authority to arbitrate the talk burst, and transmitted to a corresponding PoC client via the PF, which manages the corresponding PoC client. The Floor Granted signal may be transmitted without passing through the SIP/IP core network since it uses a bearer's route instead of an SIP protocol. The PoC user, who finally confirms the ring back tone, transmits a media stream (e.g. voice) using an Real-time transport protocol (RTP) protocol.
FIG. 3 shows a conventional call processing procedure of the terminating side based on the assumption of successful session establishment when a pre-established session is set up between a server and client of the terminating side in correspondence to the aforementioned call processing procedure of the originating side.
It is assumed that media attribute values between a PoC server and a PoC client that set up a pre-established session make use of designated attribute values with no change when a new session is requested.
An INVITE message received from an originating side network is transmitted to a PoC server belonging to the home network of a terminating PoC client through an SIP/IP core network according to the call processing procedure of an IMS network (S31, S32 and S33). At this time, a PF B sets a setup value of its answering mode in an auto answer mode, and thus transmits an SIP 200 OK message to the originating side network in response to the INVITE request message (S34, S35 and S36). The PF B does not transmit the INVITE message to the PoC client that is connected therewith because it is unnecessary to change the pre-established session.
Meanwhile, the PoC server, CF X, of a controlling network which receives an OK response returned through an IMS route transmits the OK response to the originating PoC client, and thereby completes the PoC call processing procedure (S37), and transmits a Floor Granted signal that grants the talk burst floor, to the originating PoC client (S38). Further, the CF transmits an RTCP signal of granting the floor, and simultaneously transmits a Receiving Talk Burst signal, that includes a PoC address or display name of the PoC user having the floor, to a terminating PoC user (S39 and S40). Thereby, the CF enables a terminating PoC client to receive beforehand sender's information of a media stream to be transmitted in the future. This talk burst transmission signal can be transmitted without passing through the SIP/IP core network because it uses a bearer's route instead of an SIP. Meanwhile, the media (voice) stream that is ultimately sent from the originating side is transmitted to a PoC client B through the bearer's route using an RTP, and thereby the PoC call is initiated.
According to the prior art, the following are technical problems that negatively affect the user.
First, the originating PoC client repeatedly transmits the INVITE message in order to establish the PoC multimedia session.
Second, the originating PoC client separates and transmits audio and video through two independent sessions, each of which has been established. Thus, additional support making it possible to be subject to the same floor control is required. However, the conventional PoC system does not support this function, the creating a need for a technical solution to this problem.
Fourth, in the originating PoC client's position, since the INVITE message is repeatedly transmitted in order to separate the media and then establish the session, a long time is required to obtain the floor.